1. Field of the Invention
The present invention relates generally to delivering file based media content, and in particular, to a method, apparatus, system, article of manufacture, and computer readable medium for efficiently delivering different media content deliverables to multiple entities.
2. Description of the Related Art
File based media content may be provided/delivered to a variety of different entities for viewing or further modifications. Each of the different entities may have different requirements for the file-based media content relating to both the media content itself as well as the specification/format of the media content. Further, once such content has been created, the content must be delivered to the different entities. The prior art process for selecting the relevant media content, scheduling such content for delivery, and confirming delivery of the content is a manual and time consuming task. To better understand these prior art delivery problems, a description of prior art media content processing and delivery is useful.
Different entities or different receiving mediums may have different requirements for the file-based media content. For example, a first web based entity that is going to display/stream the media content across the Internet to end-users may require the media content in MPEG2 (motion pictures expert group version 2) while a second web based entity may require the media content in MPEG-4. In another example, a domestic broadcasting entity may require the media content in NTSC (national television system committee) 4×3 aspect ratio, 30 fps (frames per second) while a foreign broadcasting entity may require PAL (phase alternating line) 16×9 aspect ratio at 25 fps. Further, the content itself may be modified or edited per the requirements of the receiving entity (e.g., shorter/no commercials, or no black bars on a 4×3 formatted program, etc.). The different versions of the media content is referred to herein as a deliverable.
Such media content is obtained/created using a variety of mechanisms (e.g., film, video, computer generated, etc.) and stored onto tape. The media content may then be transformed/encoded, transcoded into a file-based deliverable. The various deliverables are then manually delivered to the desired recipient(s).
The prior art transformation of the master (i.e., media content on tape) into a file-based deliverable is a time-consuming and inefficient process. FIG. 1 illustrates the prior art process for creating a deliverable. The tape 102 is first processed via a capture tool that transforms the media content into a file 104. A variety of products from different manufacturers (e.g., from Digital Rapids™, AmberFin™, etc.) may be used to perform the capture. Once in a file 104, the media content can be used to feed multiple different deliverables 110.
To provide a deliverable 110, the source file must be transcoded from the master into the deliverable format. To configure the transcoder, a profile 106 for each deliverable 110 is established. A profile 106 includes configuration parameters and determines what is needed in the file 104 to be used as the deliverable 110. Such configuration parameters may include height and width, bit rate, type of compression, compression ratio, etc. As described above, a television show configured for broadcast viewing may be very different than that for Internet viewing (e.g., media content may be shot with very dark lighting for broadcast that would not be acceptable for Internet viewing). Accordingly, the television show would need one deliverable 110 for the particular broadcast viewing and a second deliverable 110 for the particular Internet viewing.
Each different profile 106 is associated with a single watch folder 108. When a user desires to generate a particular deliverable 110, the user drops the file 104 into the desired watch folder 108. The profile 106 is then automatically applied to the file 104 to generate/encode/transcode the deliverable 110. To activate another profile 106 and produce a different deliverable 110, the user must manually drop the file 104 into a different watch folder 108. For example, a user may drop the file 104 into watch folder 108C. Profile 106C would then be applied to generate/encode/transcode deliverable 110C. To create a different deliverable 110B, the user would drop the file 104 into watch folder 108B. Accordingly, users need to maintain a knowledgebase regarding which watch folder 108 corresponds to which profile 106 and manually move a file 104 into a particular watch folder 108 in order to generate the desired deliverable 110. The process 100 consumes the entire file 104 and produces a deliverable 110 as a single file.
Once the deliverable 110 has been created, it must be delivered to the various clients. Some prior art mechanisms utilized tape which was manually delivered to the recipients. Alternatively, many entities have migrated towards an electronic and file based transfer system where files are digitally created and either manually delivered on tape or electronically transmitted to the recipient.
FIG. 2 illustrates the logical flow for delivering a deliverable 110 to a recipient/client in the prior art. At step 202, the user was required to manually pick/select the various file(s)/combination of file(s) to be delivered in an application. In this regard, each deliverable 110 may include various files such as a video file, audio file, metadata, closed-captions, etc. that had to be manually selected.
Once the files have been picked/selected, the user would logon to a portal or delivery mechanism and schedule the delivery of the selected files at step 204. Such a scheduling may be provided using a website, a high speed file transport service (e.g., ASPERA™), or other mechanism. Website/portal based schedulers may only permit a single individual to schedule delivery at any given time. Accordingly, if multiple users are logged into the same scheduler or portal, each person may be forced to wait until another person completes their scheduling activity. In this regard, the prior art capability to perform multi-track scheduling is limited.
Further, to ensure security and prevent inadvertent intrusions into their network from the outside, many facilities physically separate their production network from the outside viewing delivery network (WWW/Internet). This requires that files have to be manually transferred from the internal production network to interim storage, a “digital dock”, from where it may then be delivered to the clients. In this regard, the prior art capability to perform the hop from production storage to the digital dock is very limited, and has to be executed manually.
Once scheduling is complete and the deliverable 110 has been delivered, a confirmation of delivery must be forwarded (e.g., via email) at step 206. The configuration and transmission of the confirmation email must also be manually established by the media content owner (or entity that is scheduling the delivery at step 204).
The performance of steps 202-206 consumes a considerable amount of the user's time. In fact, these three steps may consume fifty percent (50%) of the user's overall deliverable creation and transmission process.
In addition to the above, many of the deliverables or other post production tools (utilized in the delivery process) are created using specific third party tools that are not web-based but rely on different protocols (e.g., TCP/IP [transmission control protocol/Internet protocol] and SSH [secure shell network protocol]). Accordingly, post production applications (e.g., an application configured to perform steps 202-206) must be individually configured to accommodate the different third party tools and protocols. Further, as the third party tools change or as new tools are released, the post production applications 202-206 must be individually changed to accommodate the new/modified versions. Further yet, with different machines executing the same post production applications 202-206, job synchronization amongst the different machines and the exclusion of the same third party tool across the different machines is difficult to implement and manage (and may often require a specific job queue).
In view of the above, what is needed is the capability for a post production application to easily, efficiently, and automatically pick, schedule, deliver, and provide delivery confirmation of multiple deliverables.